Date: Fri, 21 Jan 94 04:30:08 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #17 To: tcp-group-digest TCP-Group Digest Fri, 21 Jan 94 Volume 94 : Issue 17 Today's Topics: TCP-Group Digest V94 #16 TCP MSS and TCP WIN settings (3 msgs) TNOS Missing Function - NOT (2 msgs) Wampes loopback (3 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 21 Jan 94 09:50:38 GMT From: A.D.S.Benham@bnr.co.uk Subject: TCP-Group Digest V94 #16 To: TCP-Group@UCSD.EDU > ------------------------------ > > Date: Wed, 19 Jan 94 16:46:28 CST > From: Jack Snodgrass > Subject: TCP MSS and TCP WIN settings > To: tcp-group mailling list > > Is there any way to assign a TCP WIN and TCP MSS setting per port? 9600b ports > can use larger Window's and Packets than 1200b ports. I'm sure that it's been > asked before but now that I've got a 9600b port going, I need to know what to > do to get the most out of the system. Thanks. > > 73's de Jack - kf5mg > Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 > AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 > Dialup - kf5mg@tcet.unt.edu - work (looking for) I put the window mod into my JNOS sources last year. I'll post the deltas next week. The settings are set with the "ifconfig " subcommands. Setting the window is slightly more complicated than it might at first appear, because when one initiates a session on port the reverse path traffic might arrive on port . I therefore use the "tcp window" for the SYN frame, and then set the window on all other outgoing frames for that session according to the value set for the window on the port on which the replies are received. Don't worry if it sounds too complicated, I'll mail the deltas. 73, Andrew Benham, G8FSL -------------------------------------------------------------------- adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA adsb@bnr.ca +44 279 402372 Fax: +44 279 402029 Home: g8fsl@g8fsl.ampr.org [44.131.19.165] -------------------------------------------------------------------- ------------------------------ Date: Wed, 19 Jan 1994 19:19:08 -0800 From: Phil Karn Subject: TCP MSS and TCP WIN settings To: kf5mg@kf5mg.ampr.org If the physical port is on the same machine as the TCP, then TCP already limits its MSS to avoid fragmentation out through that port. For example, if the other end advertises that it will accept a MSS of 1460 bytes but the MTU of the local interface you'll take to reach it is only 576 bytes, then the local TCP will use a MSS of only 536 bytes (576-40). If the interface with the small MTU is on another router, however, the originating TCP won't know this and fragmentation will occur. Note also that the effective window size used by TCP, the "congestion window" is always less than the window advertised by the other end. The congestion window size is controlled by the slow start and congestion control algorithms in TCP. These are not perfect, but they do help. Phil ------------------------------ Date: Thu, 20 Jan 94 05:53:01 CST From: Jack Snodgrass Subject: TCP MSS and TCP WIN settings To: tcp-group@ucsd.edu Phil Karn writes: > If the physical port is on the same machine as the TCP, then TCP > already limits its MSS to avoid fragmentation out through that port. > For example, if the other end advertises that it will accept a MSS of > 1460 bytes but the MTU of the local interface you'll take to reach it > is only 576 bytes, then the local TCP will use a MSS of only 536 bytes > (576-40). Well... that's what I thought should happen, but I tried it with JNOS 1.10x15. There's a IFCONFIG MTU command that I used to set the MTU to a value of 256. The MSS was 1024 and the WINDOW was 4K. When I made a FTP connect, I figured that NOS would use 256 byte packets, but it used 512 byte packets. The IFCONFIG MTU value didn't seem to have an effect. I took a look at the TCP*.C files. There are only a couple of places where the Tcp_mss and Tcp_window settings are assigned to a connection. It appears that it would be easy to change this to a Tcp_mss.Interface and Tcp_window.Interface so that you could use different Window and MSS sizes per interface. The only problem is I don't see where in the TCP*.C code that it references what Interface it's using. Any idea how to tell what Interface a TCP socket is going to be using? 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 Dialup - kf5mg@tcet.unt.edu - work (looking for) ------------------------------ Date: Thu, 20 Jan 1994 14:10:25 -0600 From: miltonm@inetnode.austin.ibm.com (Milton Miller) Subject: TCP MSS and TCP WIN settings To: kf5mg@kf5mg.ampr.org mss is automatically lowered to mtu-40 based on the mtu of the first hop in the routing table. For window, you would have to rely on the congestion window I guess. Some tcp stacks have started keeping mtu in the routing table (probably only those that use the "new" mtu probing. Who is adding that to nos? :-) milton -- Milton Miller KB5TKF miltonm@austin.ibm.com I never speak for IBM ------------------------------ Date: Thu, 20 Jan 94 09:02:13 EST From: brian@lantz.cftnet.com (Brian A. Lantz) Subject: TNOS Missing Function - NOT To: tcp-group@ucsd.edu Come on, guys! It's a little unfair to blame TNOS for not including standard BorlandC 3.x DOS library functions in case you are running a version of the compiler that is 2-3 years old! The before mentioned function is a part of Borland's library for versions 3.0, 3.1, and 4.0. Lack of memory.... Borland C 3.x and up uses EMS/XMS to permit virtually unlimited source size. Is this file big, yep! As for the commment about it being perfect out of the box, NOT! If you expected that it would compile under every possible combination, your expectations are based in the clouds! Your mileage will vary! As for TNOS support, I suggest subscribing to TNOS-TOPICS and sending the messages there. I don't know that Brian wants a lot of "how do you compile this TNOS feature" stuff in this group. We don't want to abuse his understanding. /----------------------------------------------/ / Brian A. Lantz/KO4KS / / / / Packet: KO4KS@KO4KS.#TPAFL.FL.USA.NA / / Internet: brian@lantz.cftnet.com / / { printf ("Hey Jude"); / / bad = !make; / / better = sad_song; } / /----------------------------------------------/ ------------------------------ Date: Fri, 21 Jan 94 04:26:00 -0000 From: mikebw@bilow.uu.ids.net (Mike Bilow) Subject: TNOS Missing Function - NOT To: tcp-group@ucsd.edu Cc: brian@lantz.cftnet.com In a msg on , Brian A. Lantz writes: BAL> Come on, guys! It's a little unfair to blame TNOS for not BAL> including standard BorlandC 3.x DOS library functions in BAL> case you are running a version of the compiler that is 2-3 BAL> years old! The before mentioned function is a part of BAL> Borland's library for versions 3.0, 3.1, and 4.0. The _dos_xxxx() form (like "_dos_getfileattr()") of the Borland library calls was added for increased source level compatibility with Microsoft library calls as of BC++ 3.0. These are made equivalent in system header macro definitions to the old form Borland calls (like "getfileattr()"). Another motivation for the change was to more clearly indicate which functions are not part of the ANSI C specification because they are specific to the operating system or platform. ANSI suggests that such symbols be started with the extra prepended underscore character. Similar changes were made in designating "near" and "far" keywords as "_near" and "_far" in newer compilers. It would be fairly easy to generate a special header file for older Borland compilers that would implement some extremely simple text translations, such as defining the newer prefaces (like "_dos_") so that they were stripped by translating them to empty text strings. This special header file would have to be included ahead of any system header files. Somebody has probably already done this somewhere, but I don't know of it. Changes to the Borland assembler are a more irritating situation. Borland doesn't really seem to care very much about the quality of TASM, essentially regarding it as a throwaway product. Source code that assembles perfectly with TASM 2.5 (from BC++ 2.0) breaks substantially under the newer TASM 3.1 (from BC++ 3.1), a known fact for a long time. You almost never see this with the C compilers, where source code only breaks in the opposite direction, going from newer to older compilers. The most irritating part of it for me is that TASM actually has a switch which is supposed to allow it to emulate any prior version of TASM or MASM, but it doesn't work right. Probably the best solution would be to provide a prebuilt ASMOBJ.LIB of the assembly modules as Phil does for the base KA9Q source kit; he originally started doing this when TC 2.0 was all that some people had and Borland didn't even make an assembler. BAL> Lack of memory.... Borland C 3.x and up uses EMS/XMS to permit BAL> virtually unlimited source size. Is this file big, yep! BC++ 2.0 comes with two different command-line versions, BCC.EXE and BCCX.EXE. BCC runs in real mode, while BCCX runs in protected mode with an included DOS extender. You can also use compiler switches on BCC to enable it to use XMS/EMS while compiling. There are some bugs in the old Borland tools that can cause serious XMS/EMS corruption, and this can be devastating if you are running SMARTDRV or a similar disk cache which maintains disk buffers in XMS/EMS. BCCX spawns the real mode linker, TLINK, instead of the protected mode linker, TLINKX. If you use the "-l" switch on BCCX to pass an argument to the linker which enables the use of XMS/EMS, then this will conflict with the loaded DOS extender and very bad things will occur. When using BCCX, you must either live with the real mode linker and no XMS/EMS, or use the protected mode linker manually by starting TLINKX from the command line. By default, NOS MAKEFILEs invoke the compiler as a final step just to run the linker, and this might have to be changed. The real mode linker should work fine for NOS in most cases, since you will probably run out of DGROUP space long before you run out of symbol space. As was noted by someone else, the MAKE utility can be invoked with the "-S" switch to enable swapping itself out of memory, but there is a fairly serious speed penalty for that. When I was compiling NOS on a 386SX-16 in the old days, it took about an hour from scratch. On my current system, running the compiler in an OS/2 DOS emulation with DPMI seeing a lot of virtual memory, it takes about three or four minutes. BAL> As for TNOS support, I suggest subscribing to TNOS-TOPICS and BAL> sending the messages there. I don't know that Brian wants a BAL> lot of "how do you compile this TNOS feature" stuff in this BAL> group. We don't want to abuse his understanding. Why are you referring to yourself in the third person? Have you been reading "The Education of Henry Adams" or something? -- Mike ------------------------------ Date: Thu, 20 Jan 94 15:55:30 EDT From: "Jan Jaeger" Subject: Wampes loopback To: tcp-group@ucsd.edu I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3). I seem to have run into a problem where packets send over the loopback interface cause wampes to crash. The problem is that loopback->send is defined as NULLFP in iface.c and ip_route() tries to call (loopback->send). I have also compiled wampes in an RS6K (3.2.4) and the same problem exist. Am I safe to assume that this is not a porting problem? (It still needs to be fixed of course). Jan PA3EFU/VK3CEX ------------------------------ Date: Thu, 20 Jan 94 21:40:00 MST From: Dieter Deyke Subject: Wampes loopback To: JANJ@ACCIVM.acci.COM.AU, tcp-group@ucsd.edu > I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3). Could you send me your changes, so I can merge them into the distribution? > I seem to have run into a problem where packets send over the loopback > interface cause wampes to crash. The problem is that loopback->send > is defined as NULLFP in iface.c and ip_route() tries to call (loopback->send). > I have also compiled wampes in an RS6K (3.2.4) and the same problem exist. > Am I safe to assume that this is not a porting problem? (It still needs to > be fixed of course). This can only happen if you set up a route to some address different from 127.0.0.1 thru the loopback interface. Just don't do this. In the next version of WAMPES I will put in a safeguard, which will ignore packets routed this way, instead of crashing the system. > Jan PA3EFU/VK3CEX -- Dieter Deyke - deyke@fc.hp.com - dk5sg@db0sao.ampr.org ------------------------------ Date: Fri, 21 Jan 94 05:01:00 -0000 From: mikebw@bilow.uu.ids.net (Mike Bilow) Subject: Wampes loopback To: tcp-group@ucsd.edu Cc: JANJ@ACCIVM.acci.COM.AU In a msg on , Jan Jaeger of writes: JJ> I have ported wampes to the IBM RT (6150 & 6151) running AOS (BSD 4.3). Great! We have one of those dinosaurs here. Unfortunately, it is running AIX. Still worse, it is running AIX v2, since AIX v3 needs the RS machines and will not run on the RT machines. I think we have the native TCP/IP support, but no one knows where the manual is, and no one at IBM seemed to care much about locating another one even when we dangled small bills in front of them. Is your port available at any FTP site, ideally UCSD.EDU? -- Mike ------------------------------ End of TCP-Group Digest V94 #17 ******************************